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1 Abstract 


The EG6 navigation team at NASA Johnson Space Center, like any team of engineers, interacts 
with the engineering process from beginning to end; from exploring solutions to a problem, to 
prototyping and studying the implementations, all the way to polishing and verifying a final flight- 
ready design. This summer, I was privileged enough to gain exposure to each of these processes, 
while also getting to truly experience working within a team of engineers. My summer can be 
broken up into three projects: 


i) Initial study and prototyping: investigating a manual navigation method that can be utilized 
onboard Orion in the event of catastrophic failure of navigation systems, 


ii) Finalizing and verifying code: altering a software routine to improve its robustness and relia- 
bility, as well as designing unit tests to verify its performance, and 


iii) Development of testing equipment: assisting in developing and integrating of a high-fidelity 
testbed to verify the performance of software and hardware. 


2 Initial study and prototyping: Manual Navigation 


During the Apollo era, much work was put into determining methods of navigation that would not 
require significant computational resources in order to develop a backup navigation solution that 
could be used in the event of catastrophic system failure, specifically addressing the question “Can 
man navigate in space without the assistance of an electronic computer?” and “What would be 
the capabilities of such a navigation system?” In my work this summer, I have been tasked with 
studying the work of Kenneth Nordvedt, Jr., and compile a report that details his process of one- 
and two-star navigation. The result of Nordtvedt’s efforts is a system of exact linear equations 
that provide a manual navigation solution in the presence of gravity perturbations due to a third 
body; this navigation solution can be utilized onboard a spacecraft through the use of a sextant 
type device for measuring angles of either one or two celestial bodies, as well as trigonometric and 
arithmetic tables to assist in solving any difficult equations. 

The technical notes I have generated will be utilized by other interns in implementing this 
algorithm in code that can be run on the display machines onboard Orion, giving me the experience 
of being part of a team where I am playing a role upstream of my colleagues, a position that entails 
its own unique stresses and challenges. This project allowed me to explore a navigation method I was 
completely unknowledgable about, and gave me an interesting topic to delve into the mathematics 
and underlying mechanics of the algorithm. Furthermore, I have exercised my communication and 
technical writing ability knowing that my work needs to be digestable and easily convertable into 
code, invaluable experience that I don’t often get in my typical university research. 


3 Finalizing and verifying code: QUEST Algorithm 


Attitude estimation is tantamount to any navigation system; the ability to characterize the orien- 
tation of a spacecraft is a necessity to perform reliable maneuvers or even to correctly interpret 
measurements taken by onboard sensors. Magnetospheric, inertial, or even optical data is fairly 


meaningless if a system does not have some knowledge as to its attitude relative to these measure- 
ment spaces, as the mapping to the state space is undefined without it. This problem of attitude 
estimation has been well studied due to its strong need, and was formulated by Grace Wahba in 
1965 as a minimization of the cost function 


N 
1 
J(A) = 5 S ax||W, — AVz||?, 
k=l 


where V; are vectors defined in an inertial reference frame, W; are observations of these vectors 
in the relative reference frame, A is the attitude matrix of the spacecraft, and a, are arbitrary 
weights. Minimization of this function yeilds the optimal attitude estimate for the spacecraft. This 
minimization problem, known as the Wahba problem, has since been reformulated in a quaternion 
perspective by Robert Davenport, which led to Malcolm Shuster’s development of his quaternion 
estimation method in 1979, frequently referred to as QUEST (QUaternion ESTimation), or the 
q-method. 

QUEST is implemented in the Orion optical navigation software as a means of accurately char- 
acterizing the interlocking angle between the onboard startrackers and the star camera. Through 
the use of a series of calibration images, QUEST is able to provide a quaternion average for these 
images that can be used to process the star camera measurements more precisely. I was tasked 
this summer with refactoring a C code implementation of QUEST that had been generated using 
MATLAB’s autocoder, a very useful functionality of the program but one that is prone to mistakes 
in code, such as opening vulnerabilities in the code for unforeseen errors, generating code that 
in some cases might perform incorrectly or inefficiently, or code that is virtually unreadable and 
therefore difficult for a human to debug. My responsibilities included altering this code to utilize 
more in-house generated routines (as opposed to the code generated for certain common opera- 
tions such as matrix multiplication) to increase the readability and develop unit tests that would 
exercise every line of code, including failure modes. This project has enabled me to refresh my C 
coding abilities, and has given me a first exposure to developing unit tests, a process I had not gone 
through before. In addition, reworking this code and the development of these unit tests required 
me to have a fairly fundamental understanding of the QUEST algorithm, particularly in the case 
of generating failures to obtain 100% code coverage; this knowledge will be particularly useful, as 
state estimation plays a large role in a majority in my personal research. 


4 Development of testing equipment: OCILOT 


The Orion Camera-In-the-Loop Testbed (OCILOT) is a project initiated by the Orion Optical 
Navigation team to develop a testbed that best mimics a real life scenario to test Orion’s optical 
sensors and optical navigation software. The overarching plan is to work towards a complete closed- 
loop testbed setup that would allow for active navigation simulations to be performed. The loop 
is sequenced as: 


i) A machine reads in the state of the system (i.e. the position and orientation of the simulated 
spacecraft, the celestial bodies in the field of view of the spacecraft’s camera reference frame, 
the position of the sun relative to these bodies, and the star map orientation) and uses a 
program called EDGE to generate a high-fidelity image representative of this system state. 


ii) A display loads this image, which is passed through a collimator lens to redirect the light rays 
emitted from the display such that they hit a camera parallel to one another; this allows the 
light rays to be received by the camera as if they were emitted from infinitely far away, as is 
representative of space conditions. 


iii) The camera receives a command from the command and control module of the flight software 
to take an image, which is delivered to the optical navigation algorithm. 


iv) The optical navigation software determines a new estimate of the system state based on the 
image, and delivers this updated state to the EDGE software. 


The initial step towards this goal requires a slightly less complicated open-loop system. Instead of 
the flight software providing EDGE with an updated state, EDGE would be fed a precomputed 
trajectory and the camera instructed to take images at regular intervals. This allows a series of 
images to be generated for this data, providing the Optical Navigation group a set of “true” data 
on which their algorithms can be tested. 

My contributions to this project were in the display and camera controller. Due to the cost 
of collimating lenses, the lens obtained by the Optical Navigation group required a small, yet 
high-resolution display to load the images. The most appropriate was deemed to be a cell phone, 
namely a Sony Xperia Z5 Android phone. However, the use of a cellphone as a display presented 
unique challenges; the phone could not be force-fed images via USB connection, and could not 
automatically retrieve images from a remote source. Two solutions were designed to circumvent 
these issues, both requiring Android applications to be developed. The first solution was to meet 
the necessary conditions for the truth generation setup of OCILOT: an application was developed 
that allowed for the (preloaded) EDGE generated images to be scrolled through in intervals of 
arbitrary duration. The second was in support of the future closed-loop setup: a virtual private 
network (VPN) is set up on the phone to establish a secure shell (SSH) connection with the EDGE 
machine; through this SSH connection, the phone can monitor the image directory and continuously 
retrieve and display the most recent image generated by EDGE, allowing for images to be generated 
and displayed in real-time. 

The camera controller for the open-loop setup simply required a C code script that accepted 
a time interval dictating how frequently to take images and a duration of time to continue taking 
pictures. Work is still progressing towards supporting the closed-loop setup, but currently the 
camera listens on a socket for instructions to take an image, then proceeds to record the image 
in a location. Future work will require the camera controller to respond to the command and 
control module with the location of the image so that the optical navigation software knows where 
to retrieve the image from. The current state of the OCILOT setup can be observed in the figure 
below. 

This project has given me more experience with C code and makefiles, different from the QUEST 
project in that these were generated from scratch. More importantly, in the process of working 
on the Android application I have learned much of the fundamentals of Java as well as Android 
application development, two distinct skills that I had no prior experience with. While it won’t be 
particularly of use in my university studies, these languages (in particular, interfacing with remote 
machines through these languages) will be very interesting to tinker with in my free time, and will 
undoubtedly prove useful in my professional career later in life. 

In addition to the hard skills I have obtained through the duration of this project, I received 
much experience in my soft-skills as well. Each project I worked on (though primarily OCILOT 
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Figure 1. The current status of the OCILOT setup. Note that the 4K Android 
phone remotely retrieves the images via the SSH connection from the machine running 
EDGE, displays this image through a collimating lens to parallelize the light rays 
received by the camera (Cam), which delivers the image to the flight software (FSW). 


and QUEST) showed me the diversity of skills present in the Optical Navigation team (navigators, 
optics specialists, software engineers, and managers); however, OCILOT was unique in that its 
development seemed solely in the hands of interns. Three of my peers were in charge of updating 
the EDGE software with the newest star catalog to be used in simulations as well as some other 
details of the EDGE image generation, the calibration of the camera, and the design of a larger 
collimating lens to allow for a larger 8K television to be hardwired into the loop to improve image 
quality and remove the remote connection between the display and the EDGE machine. While 
the interaction with long-time NASA employees and the relationships I have built with them are 
invaluable, working with peers in internships like myself is a refreshing exercise that offers its own 
unique experience. 


5 Conclusion 


This is my second summer at NASA Johnson Space Center, and has proven to be even more useful 
than my last. The wide array of projects I worked on have given me more industry experience with 
some old skills as well as given me some new ones to take back to school with me. Experiences 
like these always refresh me and give me drive to continue my studies when I get back to my 
university, however this internship has also given me many more relationships with employees in 
the EG division and has made me more confident in the decision to strive towards a position with 
the navigation team at NASA. I hope that these relationships will continue to build, and will assist 
in me repeating this experience next summer or perhaps in a PATHWAYS position to continue to 
work towards my career goals. 


